home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98b.txt / 000050_icon-group-sender _Tue Jun 2 09:05:15 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  2KB

  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id JAA11208
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Tue, 2 Jun 1998 09:05:15 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA07969; Tue, 2 Jun 1998 09:05:08 -0700
  7. Date: Mon, 01 Jun 98 22:45:58 -0400
  8. Message-Id: <9806020245.AA0199@valinet.com>
  9. From: Paul Abrahams <abrahams@acm.org>
  10. To: ok@atlas.otago.ac.nz
  11. Cc: icon-group@optima.CS.Arizona.EDU
  12. Subject: Retrieving directory contents
  13. Reply-To: abrahams@acm.org
  14. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  15. Status: RO
  16. Content-Length: 1236
  17.  
  18. >>>>> On Tue, 2 Jun 1998 13:29:00 +1200 (NZST), "Richard A. O'Keefe" <ok@atlas.otago.ac.nz> said:
  19.  
  20. |Richard> A directory-with-file-attributes is NOT a sequence of text
  21. |Richard> lines; it is NOT a sequence, and its elements are NOT lines of
  22. |Richard> text.  Icon has the notational resources to describe what a
  23. |Richard> directory IS quite directly, and it would be a shame not to
  24. |Richard> use them.
  25.  
  26. |Richard> What is a directory with attributes?  It is a partial function
  27. |Richard> from name strings to attributes.
  28.  
  29. |Richard> Something like
  30.  
  31. |Richard>     directory(DirectoryNameString [,
  32. |Richard> FilePatternWithWildCards]) -> table with strings as keys and
  33. |Richard> attribute records as value
  34.  
  35. |Richard> would be the perfect fit to Icon.  Generation can then be
  36. |Richard> based on the existing key generation.
  37.  
  38. That certainly seems like a good approach - but I'd hate to see the
  39. whole idea of system-independent directory processing lost because the
  40. solution seems too elaborate or requires too much work.  I'm concerned
  41. about the best being the enemy of the good here.  What I care about more
  42. than anything else is seeing *some* system-independent method of
  43. retrieving the names of the files in a given directory.
  44.  
  45. Paul Abrahams
  46.  
  47.